1 - A quick tour

• 1.1 - Describing Monotone Co-Design Problems (MCDPs)
  • 1.1.A - Constant functionality and resources
  • 1.1.B - Describing relations between functionality and resources
  • 1.1.C - Units
• 1.2 - Composing MCDPs
• 1.3 - Catalogues
• 1.4 - Coproducts (alternatives)
• 1.5 - Describing uncertain MCDPs

1.1 - Describing Monotone Co-Design Problems (MCDPs)

The simplest MCDP can be defined as:

mcdp {

}

That is an empty MCDP - it has no functionality or resources.

The interface of an MCDP is defined using the keywords provides and requires:

mcdp {
    provides capacity [J]
    requires mass [g]

    # ...
}

The code above defines an MCDP with one functionality, capacity, measured in joules, and one resource, mass, measured in grams. (See how to describe types.)

Graphically, this is how the interface is represented:

1.1.A - Constant functionality and resources

The following is a minimal example of a complete MCDP. We have given hard bounds to both capacity and mass.

mcdp {
    provides capacity [J]
    requires mass [g]

    provided capacity <= 500 J
    required mass >= 100g
}

1.1.B - Describing relations between functionality and resources

Functionality and resources can depend on each other using any monotone relations.

For example, we can describe a linear relation between mass and capacity, given by the specific energy.

mcdp {
    provides capacity [J]
    requires mass [g]

    specific_energy = 4 J / g
    required mass >= provided capacity / 
                     specific_energy
}

1.1.C - Units

PyMCDP is picky about units, but generally very helpful. As long as the units have the right dimensionality, it will insert the appropriate conversions.

For example, this is the same example with the specific energy given in kWh/kg.

mcdp {
    provides capacity [J]
    requires mass [g]

    specific_energy = 200 kWh / kg
    required mass >= provided capacity / 
                     specific_energy
}

1.2 - Composing MCDPs

Suppose we define a simple model called Battery as follows:

Battery.mcdpmcdp {
    provides capacity [J]
    requires mass [g]
    specific_energy = 100 kWh / kg
    required mass >= provided capacity / 
                     specific_energy
}

Let’s also define the MCDP Actuation1:

Actuation1.mcdpmcdp {
    provides lift [N]
    requires power [W]

    l = provided lift
    p0 = 5 W
    p1 = 6 W/N
    p2 = 7 W/N^2
    required power >= p0 + p1 * l + p2 * l^2
}

Then we can combine these two together.

We can re-use previously defined MCDPs using the syntax instance `Name. The backtick means “load symbols from the library”.

The following creates two sub-design problems, for now unconnected.

mcdp {
    actuation = instance `Actuation1
    battery = instance `Battery
}

To create a complete MCDP, take “endurance” as a high-level functionality. Then the energy required is equal to endurance × power.

mcdp {
    actuation = instance `Actuation1
    battery = instance `Battery

    # battery must provide power for actuation
    provides endurance [s]
    energy = provided endurance * 
        (power required by actuation)

    capacity provided by battery >= energy
}

We can create a model with a loop by introducing another constraint.

Take extra_payload to represent the user payload that we must carry.

Then the lift provided by the actuator must be at least the mass of the battery plus the mass of the payload times gravity:

Composition.mcdpmcdp {
    actuation = instance `Actuation1
    battery = instance `Battery

    # battery must provide power for actuation
    provides endurance [s]
    energy = provided endurance * 
        (power required by actuation)

    capacity provided by battery >= energy

    # actuation must carry payload + battery
    provides payload [g]
    gravity = 9.81 m/s^2
    total_mass = (mass required by battery 
                         + provided payload)

    weight = total_mass * gravity
    lift provided by actuation >= weight

    # minimize total mass
    requires mass [g]
    required mass >= total_mass
}

1.3 - Catalogues

We can also enumerate an arbitrary relation, as follows:

catalogue {
    provides capacity [J]
    requires mass [g]

    model1 |  5 MJ | 100 g
    model2 |  6 MJ | 200 g
    model3 | 10 MJ | 400 g
}

1.4 - Coproducts (alternatives)

The coproduct construct allows to describe the idea of “alternatives”. The name comes from the category-theoretical concept of coproduct.

As an example, let us consider how to model the choice between different battery technologies.

Let us consider the model of a battery in which we take the functionality to be the capacity and the resources to be the mass [g] and the cost [$].

mcdp {
    provides capacity [J]
    requires mass [g]
    requires cost [$]

    specific_energy = 150 Wh/kg
    specific_cost = 2.50 Wh/$

    required mass >= provided capacity / specific_energy
    required cost >= provided capacity / specific_cost
}

Consider two different battery technologies, characterized by their specific energy (Joules per gram) and specific cost (USD per gram).

Specifically, consider Nickel-Hidrogen batteries and Lithium-Polymer batteries. On technology is cheaper but leads to heavier batteries and viceversa. Because of this fact, there might be designs in which we prefer either.

First we model the two battery technologies separately as two MCDP using the same interface (same resources and same functionality).

Battery_LiPo.mcdpmcdp {
    provides capacity [J]
    requires mass [g]
    requires cost [$]

    specific_energy = 150 Wh/kg
    specific_cost = 2.50 Wh/$

    required mass >= provided capacity / specific_energy
    required cost >= provided capacity / specific_cost
}

Battery1_NiH2.mcdpmcdp {
    provides capacity [J]
    requires mass [g]
    requires cost [$]

    specific_energy = 45 Wh/kg
    specific_cost = 10.50 Wh/$

    required mass >= provided capacity / specific_energy
    required cost >= provided capacity / specific_cost
}

Then we can define the coproduct of the two using the keyword choose. Graphically, the choice is indicated through dashed lines.

Batteries.mcdpchoose(
    NiH2: `Battery1_LiPo,
    LiPo: `Battery1_NiH2
)

1.5 - Describing uncertain MCDPs

The keyword Uncertain is used to define uncertain relations.

For example, suppose there is some uncertain in the value of the specific energy, varying between 100 Wh/kg and 120 Wh/kg. This is one way to describe such uncertainty:

mcdp {
  provides capacity [Wh]
  requires mass     [kg]

  required mass >= 
    Uncertain(provided capacity/120 Wh/kg ,
              provided capacity/100 Wh/kg )

}

The resulting MCDP has an uncertainty gate, marked with “?”, which joins two branches, the optimistic and the pessimistic branch.

2 - Example domains

• 2.1 - Modeling energetics constraints in a UAV
  • 2.1.A - Battery model
  • 2.1.B - Actuation
  • 2.1.C - Actuation + energetics
  • 2.1.D - Other parts
  • 2.1.E - Complete drone model
  • 2.1.F - Customer preferences in the loop
• 2.2 - The socket/plugs/converters domain
  • 2.2.A - Sockets
  • 2.2.B - Voltages
  • 2.2.C - Frequencies
  • 2.2.D - Power consumption
  • 2.2.E - Modeling a plug adapter
  • 2.2.F - A 2-in-1 adapter
  • 2.2.G - DC connectors
  • 2.2.H - USB connectors
  • 2.2.I - DC connectors
  • 2.2.J - DC power
  • 2.2.K - AC-DC converters
  • 2.2.L - Composition
  • 2.2.M - A step-up/step-down voltage converter
  • 2.2.N - A Micro USB charger
• 2.3 - The servo/motors domain
  • 2.3.A - Continuous rotation
  • 2.3.B - Rotation placement
  • 2.3.C - PWM and PPM
  • 2.3.D - Example: servo motor driven by PPM
  • 2.3.E - Example: brushless motor driven by PWM
  • 2.3.F - Example: Electronic Speed Controller
  • 2.3.G - Example: Actuation
  • 2.3.H - Example: Dagu Chassis
  • 2.3.I - The Youbot Base
  • 2.3.J - iRobot Create
• 2.4 - Space Rovers Energetics
  • 2.4.A - One option: thermocouple

2.1 - Modeling energetics constraints in a UAV

2.1.A - Battery model

A battery is specified as a DP with the functionalities:

• capacity used for each mission;
• number of missions;

and resources

• cost;
• inertial mass;
• maintenance (number of times the battery needs to be replaced).

The parameters for the model are the specific energy, the specific cost, and the number of cycles:

specific_energy = 150 Wh/kg
specific_cost = 2.50 Wh/$
cycles = 600 []

The cost for one battery is given by

unit_cost = provided capacity / specific_cost

The number of replacements is:

num_replacements = ceil(provided missions / cycles)

The total budget for the solution is given by the unit cost times the number of replacements:

required cost >= unit_cost  * num_replacements

The code below is the complete model for the battery:

Battery_LiPo1.mcdpmcdp {
    provides capacity [J]
    provides missions [R]

    requires mass     [g]
    requires cost     [$]

    # Number of replacements
    requires maintenance [R]

    # Battery properties
    specific_energy = 150 Wh/kg
    specific_cost = 2.50 Wh/$
    cycles = 600 []

    # How many times should it be replaced?
    num_replacements = ceil(provided missions / cycles)
    required maintenance >= num_replacements

    required mass >= provided capacity / specific_energy

    # cost for one battery
    unit_cost = provided capacity / specific_cost
    required cost >= unit_cost  * num_replacements
}

This is a graphical representation of the network of constraints:

2.1.B - Actuation

The actuation is defined as a DP where the functionalities are:

• the maximum platform velocity;
• the maximum lift;

and the resources are:

• cost;
• actuator inertial mass;
• power.

The model first describes some hard constraints for the quantities:

provided lift <= 100N
required actuator_mass >= 100 g
required cost >= 100 $
provided velocity <= 3 m/s

Then it describes a nonlinear polynomial (and monotone) relation between lift and power:

p0 = 2 W
p1 = 1.5 W/N^2

required power >= p0 + (lift^2) * p1

This is the complete MCDP:

Actuation.mcdpmcdp {
    provides lift  [N]
    provides velocity [m/s]

    requires power [W]
    requires actuator_mass [g]
    requires cost [$]

    provided lift <= 100N
    required actuator_mass >= 100 g
    required cost >= 100 $
    provided velocity <= 3 m/s

    p0 = 2 W
    p1 = 1.5 W/N^2

    required power >= p0 + (lift^2) * p1
}

This is the graphical representation:

2.1.C - Actuation + energetics

Next, we will define an MCDP that contains both actuation and energetics as sub-MCDPs.

We will take as high-level functionality:

• endurance (length of mission)
• extra payload: things that must be carried on board
• extra power: power to be provided for other subsystems

In the model below, first we instantiate the models of battery and actuation:

battery = new Battery_LCO
actuation = new Actuation

The power constraint can be written as follows:

total_power = power required by actuation + extra_power
capacity provided by battery >= endurance * total_power

The lift constraint is the following:

total_mass = (
     mass required by battery +
     actuator_mass required by actuation
     + extra_payload)

gravity = 9.81 m/s^2
weight = total_mass * gravity

lift provided by actuation >= weight

The cost constraint is the following:

labor_cost = (10 $) * (maintenance required by battery)

 total_cost >= (
   cost required by actuation +
   cost required by battery +
   labor_cost)

ActuationEnergetics.mcdpmcdp {
    provides endurance     [s]
    provides extra_payload [kg]
    provides extra_power   [W]
    provides num_missions [R]
    provides velocity [m/s]

    requires total_cost [$]

    battery = new Battery_LCO
    actuation = new Actuation

    total_power = power required by actuation + extra_power
    capacity provided by battery >= endurance * total_power

    total_mass = (
      mass required by battery +
      actuator_mass required by actuation
      + extra_payload)

    gravity = 9.81 m/s^2
    weight = total_mass * gravity

    lift provided by actuation >= weight
    velocity provided by actuation >= velocity

    labor_cost = (10 $) * (maintenance required by battery)

    total_cost >= (
    cost required by actuation +
    cost required by battery +
    labor_cost)

    battery.missions >= num_missions

    requires total_mass >= total_mass   
}

2.1.D - Other parts

These are other parts that we need.

Computer.mcdpmcdp {
    requires power [W]
    provides computation [flops]

    p0 = 1 W
    p1 = 100 W/flops
    power >= p0 + p1 * computation
}

Sensor.mcdptemplate mcdp {
    provides framerate [Hz]
    provides resolution [pixels/deg]
    provides fov [deg]
    requires power [W]
}

Perception.mcdptemplate mcdp {
    provides velocity [m/s]
    requires computation [flops]
    requires camera_framerate [Hz]
    requires camera_resolution [pixels/deg]
    requires camera_fov [deg]
}

Strategy.mcdpmcdp {
    provides distance [km]
    requires endurance [s]
    requires velocity [m/s]

    distance <= endurance * velocity
}

2.1.E - Complete drone model

Based on the previous models, we can assemble the model for the entire drone, with high-level functionality: travel_distance carry payload * num_missions

DroneComplete.mcdpmcdp {
    provides travel_distance [km]
    provides num_missions [R]
    provides carry_payload [g]

    requires total_cost_ownership [$]

    strategy = new Strategy

    actuation_energetics = new ActuationEnergetics

    endurance provided by actuation_energetics>= endurance required by strategy
    velocity provided by actuation_energetics>= velocity required by strategy
    num_missions provided by actuation_energetics >= provided num_missions
    extra_payload provided by actuation_energetics>= provided carry_payload
    distance provided by strategy >= provided travel_distance

    computer = new Computer
    perception = new Perception
    computation provided by computer>= computation required by perception


    sensor = new Sensor
    resolution provided by sensor >= camera_resolution required by perception
    framerate provided by sensor >= camera_framerate required by perception
    fov provided by sensor >= camera_fov required by perception

    velocity provided by perception >= velocity required by strategy
    extra_power provided by actuation_energetics >= power required by computer + power required by sensor

    # We can take into account the shipping cost
    shipping = new Shipping

    total_mass = total_mass required by actuation_energetics

    ships provided by shipping >= total_mass

    total_cost_ownership >= postage required by shipping + total_cost required by actuation_energetics
}

2.1.F - Customer preferences in the loop

Finally, we can define a model of the customer:

and put it in the loop:

CustomerPlusEngineering.mcdpmcdp {
    customer = new Customer
    robot = new DroneComplete

    budget provided by customer >= total_cost_ownership required by robot

    travel_distance provided by robot >= travel_distance required by customer
    num_missions    provided by robot >= num_missions    required by customer
    carry_payload   provided by robot >= carry_payload   required by customer
}

2.2 - The socket/plugs/converters domain

We are going to model the domain of AC sockets and plugs.

2.2.A - Sockets

There are many AC power plugs and sockets.

Type A	Type B	Type C	Type D	Type E
Type F	Type G	Type H	Type I	Type J
Type K	Type L	Type M	Type N	Type O

Some of them are compatible. For example we can fit a plug ot Type A into a socket of Type B. This creates a natural partial order structure.

We can use a finite_poset to describe the poset as follows:

socket_type.mcdp_posetfinite_poset {
  TypeA TypeB TypeC TypeD TypeE TypeF  TypeG  TypeH  
  TypeI2 TypeI3 TypeJ TypeK TypeL TypeM TypeN  TypeO

  # A <= B: if it fits in A, it also fits in B
  TypeA  <= TypeB
  TypeC  <= TypeD   
  TypeE  <= TypeD   
  TypeF  <= TypeD   
  TypeC  <= TypeE
  TypeF  <= TypeE
  TypeC  <= TypeH
  TypeI2 <= TypeI3
  TypeC  <= TypeJ
  TypeK  <= TypeC
  TypeC  <= TypeL
  TypeC  <= TypeN
  TypeC  <= TypeO

  None <= TypeA 
  None <= TypeB 
  None <= TypeC 
  None <= TypeD 
  None <= TypeE 
  None <= TypeF  
  None <= TypeG  
  None <= TypeH  
  None <= TypeI2 
  None <= TypeI3 
  None <= TypeJ 
  None <= TypeK 
  None <= TypeL 
  None <= TypeM 
  None <= TypeN  
  None <= TypeO
}

2.2.B - Voltages

Around the world, the two main voltages are 110V and 220V. In this case, we cannot use the usual Volt poset indicated by V, because that would mean that 220V is always preferable to 110V.

Thus we create a discrete poset as follows:

AC_voltages.mcdp_posetfinite_poset {
  v110 v220
}

2.2.C - Frequencies

Similarly, we model different frequencies with the poset

AC_frequencies.mcdp_posetfinite_poset {
    f50 f60
}

2.2.D - Power consumption

The function of a socket in the wall is to provide power. This function is parameterized (at least) by:

• The socket shape, indicated by `socket_type

• The voltage, indicated by `AC_voltages

• The frequency, indicated by `AC_frequencies

• The maximum power draw, measured in Watts. (Alternatively, this could be parameterized by current.)

Therefore, we can create the poset `AC_power as follows:

AC_power.mcdp_posetproduct(
       socket: `socket_type,
      voltage: `AC_voltages,
    frequency: `AC_frequencies,
        watts: W
)

2.2.E - Modeling a plug adapter

Based on these definitions, we can define the function of a socket adapter.

Consider one of these OREI adapters, which you can buy for $7.31:

This is an adapter from Type L to either Type C or Type A:

Type L

Type A

Type C

A plug adapter can be modeled as follows:

orei.mcdp# This device converts from TypeC to either TypeL or TypeA
mcdp {
    provides out [`AC_power]
    requires in  [`AC_power] 
    requires budget [USD]

    budget >= 7.31 USD

    (required in).socket >= `socket_type : TypeL
    (required in).voltage   >=  (provided out).voltage
    (required in).frequency >=  (provided out).frequency
    (required in).watts     >=  (provided out).watts

    (provided out).socket <= any-of({`socket_type : TypeA, `socket_type : TypeC})
}

2.2.F - A 2-in-1 adapter

This is another handy 2-in-1 adapter that sells for 6.31:

This one provides 2 outputs:

orei_2in1.mcdpmcdp {
    provides out1 [`AC_power]
    provides out2 [`AC_power]
    requires in  [`AC_power] 
    requires budget [USD]

    budget >= 6.31 USD
 
    (required in).socket >= `socket_type : TypeM

    (provided out1).socket <= any-of({`socket_type : TypeA, `socket_type : TypeC})
    (provided out2).socket <= any-of({`socket_type : TypeA, `socket_type : TypeC})

    # this forces the two voltages to be the same
    (required in).voltage   >=  (provided out1).voltage
    (required in).voltage   >=  (provided out2).voltage
    (required in).frequency >=  (provided out1).frequency
    (required in).frequency >=  (provided out2).frequency
    # this says that the power sums
    total_power = (provided out1).watts + (provided out2).watts
    (required in).watts >=  total_power
}

We can forget all this complexity and consider the block:

2.2.G - DC connectors

We can repeat the same story with DC connectors.

barrel_connectors.mcdp_posetfinite_poset {
    tip_sleeve_2_5mm
    tip_sleeve_3_5mm
    barrel_5mm
    # EIAJ-01 (2.35mm barrel, 0.7mm inner diameter)
    barrel_2_35mm
    barrel_3_35mm_1_35mm
    # EIAJ-02 (4.0mm barrel, 1.7mm inner diameter)
    barrel_4mm_1_7mm
    barrel_4mm_1_5mm
    barrel_4mm_2_5mm

    # used by Youbot charger
    Neutrik_NC4MXX

    barrel_none
    barrel_none <= tip_sleeve_2_5mm
    barrel_none <= tip_sleeve_3_5mm
    barrel_none <= barrel_5mm
    barrel_none <= barrel_2_35mm
    barrel_none <= barrel_3_35mm_1_35mm
    barrel_none <= barrel_4mm_1_7mm
    barrel_none <= barrel_4mm_1_5mm
    barrel_none <= barrel_4mm_2_5mm
    barrel_none <= Neutrik_NC4MXX
}

2.2.H - USB connectors

USB_connectors.mcdp_posetfinite_poset {
    # female (socket)
    none_usb <= USB_Micro_A 
    none_usb <=    USB_Micro_B
    none_usb <=    USB_Mini_A
    none_usb <=    USB_Mini_B
    none_usb <=    USB_Std_A
    none_usb <=    USB_Std_B
    none_usb <=    USB_Type_C
    # male
    none_usb <=    USB_Micro_A_male
    none_usb <=    USB_Micro_B_male
}

2.2.I - DC connectors

We can define DC connectors to be the union (co-product) of the two sets:

DC_connectors.mcdp_posetcoproduct(`barrel_connectors, `USB_connectors)

2.2.J - DC power

DC_voltages.mcdp_posetfinite_poset {
  v1_5 v5 v6_6 

  none_voltages <= v1_5
  none_voltages <= v5
  none_voltages <= v6_6
}

DC_power.mcdp_posetproduct(
 connector: `DC_connectors,
   voltage: `DC_voltages,
      amps: A
)

2.2.K - AC-DC converters

This wall charger can be used to convert from AC power to DC power.

Ravpower.mcdpmcdp {
    provides out1 [`DC_power]
    provides out2 [`DC_power]
    requires in  [`AC_power] 
    requires budget [USD]

    budget >= 10.99 USD    

    (required in).socket >= `socket_type : TypeA

    (provided out1).voltage   <= `DC_Voltages: v5
    (provided out2).voltage   <= `DC_Voltages: v5
    (provided out1).connector <= `USB_connectors:USB_Std_A 
    (provided out2).connector <= `USB_connectors:USB_Std_A

    # this forces the two voltages to be the same
    # this says that the power sums
    amps = (provided out1).amps + (provided out2).amps
    amps <= 2.4 A
    power = 5 V * (amps)

    (required in).watts >= power
    (required in).voltage >= `AC_voltages: v110
    (required in).socket >= `socket_type: TypeA
    (required in).frequency >= `AC_frequencies: f50

}

We can query the model as follows. Suppose we need 2 outputs, each of 0.5A.

solve(
    ⟨ ⟨ `USB_connectors:USB_Std_A, `DC_voltages: v5, 0.5 A⟩,
      ⟨ `USB_connectors:USB_Std_A, `DC_voltages: v5, 0.5 A⟩ ⟩, 
    `Ravpower)

This is the output:

↑{⟨in:⟨socket:'TypeA', voltage:'v110', frequency:'f50', watts:5 W⟩, budget:10.99 USD⟩}

The model says we have two options: we need to find an outlet of TypeM at either 110 V or 220 V which will provide 5 W of power. Moreover, we need at least 10.99 USD to buy the component.

2.2.L - Composition

This is an example of composition of the Ravpower charger and the Orei_2in1 adapter.

orei_plus_ravpower.mcdpmcdp {
    provides out [`DC_power]   
    requires in [`AC_power]   
    requires budget [USD]  
    charger = instance `Ravpower
    adapter = instance `Orei_2in1
    in required by charger <= out1 provided by adapter
    required in >= in required by adapter
    provided out <= out1 provided by charger 
    # sum the budget together
    budget >= budget required by charger + budget required by adapter
    # ignore the functions we don't need
    ignore out2 provided by charger 
    ignore out2 provided by adapter
}

Note the use of the keyword “ignore” to ignore the functionality that we do not need.

We can ask now for what resources we would need for a 0.5 A load:

solve(
    ⟨ `USB_connectors:USB_Std_A, `DC_voltages: v5, 0.5 A⟩,
    `orei_plus_ravpower)

and obtain

↑{⟨in:⟨socket:'TypeM', voltage:'v110', frequency:'f50', watts:2.5 W⟩, budget:17.3 USD⟩}

2.2.M - A step-up/step-down voltage converter

Next, we are going to model a Goldsource STU-200 Step Up/Down Voltage Transformer Converter.

This is a device with 1 input and 3 outputs:

goldsource_STU_200.mcdpmcdp {
   # This provides 3 outputs: 2 AC and 1 DC
   provides out1 [`AC_power]
   provides out2 [`AC_power]
   provides out3 [`DC_power]
   requires in [`AC_power]
 
   # the AC output 1 is v110 and takes types A, B (A<=B)
   (provided out1).socket <= `socket_type: TypeB 
   (provided out1).voltage <= `AC_voltages:v110
   (provided out1).frequency <= (required in).frequency # same frequency
   power1 = (provided out1).watts

   # the AC output 2 is v220 and takes types C, D, E, F, G, H (D,G minimals)
   (provided out2).socket <= any-of({ `socket_type: TypeD, `socket_type: TypeG })
   (provided out2).voltage <= `AC_voltages:v220
   (provided out2).frequency <= (required in).frequency # same frequency
   power2 = (provided out2).watts

   # the DC output is 5v, USB Type A
   (provided out3).connector <= `USB_connectors: USB_Std_A
   (provided out3).voltage   <= `DC_voltages: v5
   amp3 = (provided out3).amps
   power3 = 5 V * (amp3)
   
   power = power1 + power2 + power3
   (required in).watts >= power

   # input is either typeC or typeD (C<=D)
   (required in).socket >= `socket_type: TypeC
   (required in).frequency >= `AC_frequencies: f50 # XXX
   (required in).voltage >= `AC_voltages: v110 # XXX
}

2.2.N - A Micro USB charger

USBMicroCharger.mcdpmcdp {
    provides out [`DC_power] 
    requires in  [`AC_power] 
    requires budget [USD]

    budget >= 10.99 USD    

    (required in).socket >= `socket_type: TypeA
    (required in).voltage >= `AC_voltages: v110
    (required in).frequency >= `AC_frequencies: f50

    (provided out).voltage   <= `DC_voltages: v5
    (provided out).connector <= `USB_connectors: USB_Micro_A_male
     
    amps = (provided out).amps 
    amps <=  2.4 A
    power = 5 V * (amps)

    (required in).watts >= power
}

2.3 - The servo/motors domain

This is a formalization of the domain of servos/DC motors and accessories.

2.3.A - Continuous rotation

The functionality ContinuousRotation describes a device that can provided continuous rotation along an axis.

This functionality is parameterized by:

• torque: maximum torque provided;
• velocity: maximum velocity (rad/s).

ContinuousRotation.mcdp_posetproduct( 
  torque: N*m,
  velocity: rad/s,
  duration: s,
  rigid_body: `RigidBodyID
)

2.3.B - Rotation placement

The functionality AngularPlacement describes what a servo mechanism provides: precise placement along a rotational axis.

This functionality is parameterized by:

• torque;
• span [deg]: how much it can travel;
• transit_time_60deg: the time it takes for the servo to travel 60 deg;
• resolution [deg]: how precisely it reaches the desired position.

AngularPlacement.mcdp_posetproduct (
   resolution: deg,
   torque: N*m,
   span: deg, 
   transit_time_60deg: s, # XXX: this should be "opped"
   duration: s,
   rigid_body: `RigidBodyID
)

2.3.C - PWM and PPM

The two main ways to drive motors are Pulse-Width Modulation (PWM) and Pulse-Position Modulation (PPM).

For PWM, the variables of interest are:

• voltage_max: the maximum voltage;
• amp_max: maximum current that can be provided;
• freq_max: the maximum switching frequency.

PWM.mcdp_posetproduct(
 voltage_max: V,
 amp_max: A,
 freq_max: Hz,
 duration: s,
 rigid_body: `RigidBodyID
)

For PPM, the variables of interest are:

• voltage_max: maximum voltage ;
• amp_max: maximum current;
• freq_max: the maximum frequency;
• resolution: resolution of the generated PPM.

PPM.mcdp_posetproduct(
 voltage_max: V,
 amp_max: A,
 freq_max: Hz,
  resolution: R, # number between 0 and 1, lower is better
 # resolution: op(R) # number between 0 and 1, lower is better
 duration: s,
 rigid_body: `RigidBodyID
)

2.3.D - Example: servo motor driven by PPM

A servo motor like the Traxxas 2075 Digital High-Torque Waterproof Servo is a device that provides the `AngularPlacement functionality, and to do so requires the `PPM resource.

Traxxas_2075.mcdpmcdp {
   provides angular_placement [`AngularPlacement]
   requires ppm [`PPM]

   requires budget [USD]
   requires payload [`Payload]
   
   (required ppm).voltage_max >= 6 V
   (required ppm).amp_max >= 1 A # XXX
   (required ppm).freq_max >= 50 Hz
   (required ppm).resolution >= 0.0028   []
   (provided angular_placement).transit_time_60deg <= 0.17s   
   (provided angular_placement).torque <= 0.882 N * m
   (provided angular_placement).resolution <= 1 deg # XXX
   (provided angular_placement).span <= 360 deg # XXX
   (required ppm).duration >= (provided angular_placement).duration

   rigid_body = (provided angular_placement).rigid_body

   (required ppm).rigid_body >= rigid_body

   required budget >= 27.99 USD
   (required payload).shape >= <55mm, 20mm, 42.3mm>
   (required payload).mass >= 45 g 
   (required payload).rigid_body >= rigid_body
}

2.3.E - Example: brushless motor driven by PWM

A brushless motor like the Traxxas 3351 provides the `ContinuousRotation functionality and requires the `PWM resource.

Traxxas_3351.mcdpmcdp {
   provides cr [`ContinuousRotation]
   requires pwm [`PWM]
   requires budget [USD]   

   requires payload [`Payload]
   
   required budget >= 99.28 USD
   (required payload).mass >= 1.6 pounds
   (required payload).shape >= <6.5in, 2in, 5.8in>
   rigid_body = (provided cr).rigid_body
   (required payload).rigid_body >= rigid_body
   (required pwm).rigid_body >= rigid_body

  (provided cr).torque <= 0 N*m
  (provided cr).velocity <= 5000 rpm

   (required pwm).freq_max >= 1600 Hz

   rating = 3500 rpm / V 
   (required pwm).voltage_max >= (provided cr).velocity / rating

   # the amps are related to the torque
   eff = 0.75 []
   (required pwm).amp_max *  (required pwm). voltage_max
       >= eff * (provided cr).torque *  (provided cr).velocity 

  (required pwm).duration >= (provided cr).duration
}

2.3.F - Example: Electronic Speed Controller

An electronic speed controller (ESC) like the VESC can drive servos/motors using PPM/PWM.

mcdp {
    provides ppm [`PPM]
    provides pwm [`PWM]

    requires in [`PortableDCPower]
    requires usb [`USBCom]

    requires budget [USD]
    requires payload [`Payload]

    required budget >= 115 USD
    
    (required payload).shape >= <2cm, 2cm, 1cm>
    (required payload).mass  >= 10 g

    # XXX: these numbers were made up
    (provided pwm).voltage_max <= 5 V
    (provided pwm).amp_max  <= 2 A
    (provided pwm).freq_max <= 120 Hz

    # XXX: these numbers were made up
    (provided ppm).voltage_max <= 5 V
    (provided ppm).amp_max  <= 50 mA
    (provided ppm).freq_max <= 120 Hz
    (provided ppm).resolution <= 0.01 []

    endurance = max( (provided ppm).duration, (provided pwm).duration )
    (required in).duration >= endurance
    (required usb).duration >= endurance

    dc_in = (required in).dc
    (dc_in).connector >= `barrel_connectors: barrel_5mm # incorrect
    (dc_in).voltage >= `DC_voltages: v5
    (dc_in).amps >= 2 A

    (required payload).rigid_body >= (provided pwm).rigid_body
    (required payload).rigid_body >= (provided ppm).rigid_body
    (required in).rigid_body >= (provided ppm).rigid_body
    (required usb).rigid_body >= (provided ppm).rigid_body

}

2.3.G - Example: Actuation

product (
  rigid_body: `RigidBodyID,
  velocity: m/s,
  endurance: s
)

product(
  mass: kg,
  shape: m x m x m,
  rigid_body: `RigidBodyID
)

2.3.H - Example: Dagu Chassis

Dagu Chassis used for the Duckiebot.

mcdp {
   provides motion [`Motion]
   provides payload_bottom [`Payload] 
   provides payload_top    [`Payload] 

   requires budget [USD]
   required budget >= 15 USD

   requires pwm1 [`PWM]
   requires pwm2 [`PWM]
   
   mass = (provided payload_bottom).mass + (provided payload_top).mass 
   
   shape_top = (provided payload_top).shape
   shape_bottom = (provided payload_bottom).shape
 

   shape_top <= <14cm, 11cm, 30cm>
   shape_bottom <= <14cm, 11cm, 3cm>

   (provided motion).velocity <= 35 cm/ s

   c = 0.1 A / kg
   current = max(mass * c, 0.4 A)

   endurance = (provided motion).endurance
   rigid_body = max(max((provided motion).rigid_body, (provided payload_bottom).rigid_body),
                    (provided payload_top).rigid_body)

   (required pwm1).amp_max >= current
   (required pwm1).voltage_max >= 5 V
   (required pwm1).freq_max >= 60 Hz
   (required pwm1).duration >= endurance
   (required pwm1).rigid_body >= rigid_body

   (required pwm2).amp_max >= current  
   (required pwm2).voltage_max >= 5 V
   (required pwm2).freq_max >= 60 Hz
   (required pwm2).duration >= endurance
   (required pwm2).rigid_body >= rigid_body

   requires rb_id [`RigidBodyID] 
   required rb_id >=  rigid_body
}

2.3.I - The Youbot Base

Youbot base

mcdp {
   provides out [`PortableDCPower]
   provides usbcom [`USBCom]
   provides motion [`Motion]
   provides payload [`Payload]

   requires budget [USD]
   
   (provided motion).velocity <= 5 m/s
   required budget >= 10000 USD

   computer = instance `YoubotBaseComputer 

   provided usbcom <= usbcom provided by computer 

   battery = instance `YoubotBaseBattery

   mass = (provided payload).mass
   shape = (provided payload).shape
 

   endurance1 = max( (provided usbcom).duration, (provided motion).endurance)
   #endurance2 = (provided out).duration
   
   endurance = endurance1 

   motors = instance mcdp {
      provides endurance [s]
      requires in [`PortableDCPower]
   }

   motors.endurance >= endurance

   in required by motors  <= out3 provided by battery

  # limit x and y
   shape <= <30cm, 50cm, 50cm>
   
   mass <= 10 kg

   out1 provided by battery >= dc required by computer
   out2 provided by battery >= provided out
 
   (provided out).dc <= (out2 provided by battery).dc
   (provided out).duration <= (out2 provided by battery).duration
   

   rigid_body1 = max( (provided out).rigid_body, (provided usbcom).rigid_body )
   rigid_body2 = max( (provided motion).rigid_body, (provided payload).rigid_body )
   rigid_body = max(rigid_body1, rigid_body2)

   rigid_body <= (out2 provided by battery).rigid_body

   requires rigid_body [`RigidBodyID]
   required rigid_body >= rigid_body
   requires in for battery
}